Currently, the P2P (peer-to-peer) communication technique in network is a kind of technique which is able to directly realize the communication between two peers without a transition server. In the process of peer-to-peer communication, the approach for the connection of two clients which are located in two different network address translation (NAT) is very crucial. Specifically, the problem of traversing NAT/FW (network address translation and firewall) in peer-to-peer communication is needed to be solved. Particularly, the traversal in the application situation of symmetric NAT, a NAT with a changing and strictly restricted port and a double intranet NAT has become an intractable problem.
NAT is produced under the situation that IP address get scarce day by day in Internet. The main object of NAT is to reuse the IP address. NAT is responsible for translating the source IP address of IP data packet, which is sent from some computers with IP address of intranet to extranets, into the IP address of public network owned by NAT. The destination IP address is not changed. NAT transfers the IP data packet to the Router, and finally to the external computers. Meanwhile, NAT is responsible for translating the destination IP address of the IP data packet returned by the external computers into the IP address of intranet. The source IP address is not changed. The IP data packet is finally sent to the intranet computers.
NAT is divided into two categories: basic NAT and Network Address/Port Translator (NAPT). The basic NAT may change the IP address of an IP packet but may not change the port in the IP packet. The NAPT not only changes the IP address of an IP data packet passing through the NAT device but also changes the TCP/UDP port of the IP data packet. The characteristic of NAPT getting on Internet determines that the computers inside the NAPT may initiate a connection to the computer outside the NAPT. It is not allowed that external hosts establish connections with the computers inside the NAPT.
In order to solve the problem of traversal, there is a technique of user datagram protocol (UDP) hole punching. The concrete technique is that, when a user requests to establish communication with a corresponding user, according to the stored information, a check server determines whether the network needed to be traversed during the communication is a symmetric NAT, a NAT with a changing and strictly restricted port or a double intranet NAT or not. If the network needed to be traversed is a symmetric NAT, a NAT with a changing and strictly restricted port or a double intranet NAT, the two user terminals communicate through the transition of the server, otherwise the two user terminals communicate in the manner of peer-to-peer.
The check server and the UDP hole punching technique will be explained respectively as follows.
The check server is configured to perform a simple traversal of UDP through NATs (STUN) technique. The STUN protocol is defined by RFC 3489. The principle of the STUN protocol is to communicate with the server group located on the public network via a STUN client, and return a customer IP and address to the client. The client judges its own position according to the feedback result obtained in many kinds of situation. The client gets to know its own position information so as to offer a foundation for realizing the corresponding traversing solution.
The UDP hole punching technique above will be explained as follows.
At first, the mapping relationship table of routing address in the intranet is described. A mapping between an intranet IP address and an extranet IP address plus port is executed when a machine located in the intranet sends data outwards every time, such as:
192.168.1.1 (LAN) - - - PORT1 (extranet);
192.168.1.2 (LAN) - - - PORT2 (extranet);
The source address of the data packet is actually translated from 192.168.1.2 to a public IP of extranet and a temporarily allocated port when data are sent outwards by 192.168.1.2. The original port2 remains unchanged if the NAT is a Cone NAT. The port will change if the NAT is a symmetric NAT. However, there exists a corresponding routing relationship between the intranet IP and the extranet port.
It can be further understood as that, when an internal host (e.g. 192.168.1.2) sends a UDP packet to an external IP (e.g. 219.237.60.1), a hole is punched on the NAT device in the intranet. The direction of the hole is 219.237.60.1. After that, the external device (219.237.60.1) may communicate with 192.168.0.10 in intranet through the hole and the other internal IP may not use this hole.
The corresponding communication course is as shown in FIG. 1 if two clients are both located under the device of Cone NAT. The specific manner is as follows.
At first, a client1 logs on the server. NAT1 allocates a port for this session, e.g. 60000. The address of the client1 received by the server is 202.187.45.3:60000. This address is the extranet address of the client1. Similarly, the client2 logs on the server. NAT2 allocates a port for this session, e.g. 40000. The address of the client2 received by the server is 187.34.1.56:40000.
At this time, the client1 and the client2 may both communicate with the server. If the client1 wants to directly send information to the client2, the client1 may obtain the public network address 187.34.1.56:40000 of the client2 from the server. At this moment, as long as a hole is punched on the NAT2 and the direction of the hole is 202.187.45.3 (i.e. the extranet address of the client1), the client2 may receive the information sent by the client1 to 187.34.1.56:40000.
The operation of punching hole needs the server to instruct the client2 to send because the server keeps communicating with the client2. That is to say, the client1 sends an instruction to the server and request the server to instruct the client2 to punch a hole orienting towards the client1 if the client1 wants to send information to the client2.
However, the above course is adapted to the situation of Cone NAT. If the NAT is a symmetric NAT, the client2 may not get to know the corresponding port information and may not punch the hole because the port where the client2 punches the hole to the client1 has been renewedly allocated.
From the above introduction, it can be seen that there exists solutions to realize NAT traversal processing for the following situations:
1. At least one of the sending part and the receiving part is located in the public network.
2. The sending part and the receiving part are both located in the Cone NAT, including Full Cone, IP Restricted Cone and Port Restricted Cone.
However, with regard to the situations listed in Table.1, the solution used currently is transition communication via the server and may not truly realize P2P communication.
TABLE 1OrderThe type of the sending partThe type of the receivingnumber(client1) NATpart (client2) NAT1Symmetric NATSymmetric NAT2Port Restricted ConeSymmetric NAT3Symmetric NATPort Restricted Cone
In other word, it can be seen that traversing a basic NAT may be realized through the above technique. However, this kind of technique may not traverse the symmetric NAT and the NAT with a strictly restricted port (Port Restricted Cone).
Therefore, UDP hole punching is a simple traversal to the intranet. This technique is very limited. It's usually needed to be realized via a transition server during processing the network with a restricted port and a symmetric NAT. A peer-to-peer traversal may not be realized. The situation of transition communication service by occupying a large amount of resource of transition server may increase the cost of network operation inevitably.